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Abstract — In  any  on-demand  routing  protocol,  sources  flood 
route  requests  (RREQ)  to  build  routes  to  destinations,  and  each 
new  RREQ  is  identified  uniquely  with  a  source-sequenced  label 
(SSL)  consisting  of  the  source  identifier  and  a  locally  generated 
sequence  number.  As  a  RREQ  propagates,  it  creates  a  directed 
acyclic  graph  (DAG),  because  nodes  relay  each  RREQ  only  once. 
We  present  the  first  framework  for  loop-free  on-demand  routing 
in  ad  hoc  networks  that  is  based  directly  on  SSLs,  rather  than 
on  independent  mechanisms,  which  has  been  the  way  in  which 
prior  on-demand  routing  protocols  have  been  designed.  Extensive 
simulation  results  for  simple  protocol  instantiations  of  our  new 
framework  operating  in  scenarios  with  50  and  100-nodes  under 
different  traffic  patterns  show  that  our  new  protocols  outperform 
AODV  (Ad  hoc  On  Demand  Distance  Vector),  DSR  (Dynamic 
Source  Routing),  and  OLSR  (Optimized  Link  State  Routing). 

I.  Introduction 

Several  routing  protocols  (e.g.,  [3]  [2]  [1])  have  been 

proposed  to  deal  with  the  fundamental  problem  of  routing 
data  packets  across  multiple  hops  in  a  mobile  ad  hoc  net¬ 
work  (MANET)  using  two  different  approaches.  Pro-active 
approaches  maintain  routing  information  for  all  destinations, 
regardless  of  whether  traffic  exists  for  them.  Reactive  (on- 
demand)  approaches  maintain  routing  information  for  only 
those  destinations  for  which  traffic  exists,  and  rely  on  flood 
search  mechanisms  to  establish  routes  to  “active”  destinations. 
On-demand  protocols  are  very  attractive  in  scenarios  with  high 
mobility,  and  traffic  patterns  in  which  source  nodes  pick  a  few 
other  nodes  as  destinations. 

On-demand  routing  protocols  establish  routes  to  destina¬ 
tions  in  two  phases;  During  the  route  search  phase,  the 
network  is  flooded  with  route  requests  (RREQ).  Each  RREQ  is 
uniquely  labeled  by  its  source  by  means  of  a  source-sequenced 
label  (SSL),  which  consists  of  the  identifier  of  the  source  and 
a  source  sequence  number  that  is  locally  unique.  SSLs  prevent 
any  node  from  processing  the  same  RREQ  multiple  times,  and 
nodes  effectively  build  a  directed  acyclic  graph  (DAG)  rooted 
at  the  source  for  a  source-destination  pair  uniquely  defined  by 
the  SSL  and  the  destination  identifier. 
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During  the  route  establishment  phase,  RREQs  received  by 
the  destination  or  an  intermediate  node  with  routing  state 
for  the  destination  are  answered  with  route  reply  (RREP) 
messages  that  traverse  the  loop-free  reverse  paths  along  the 
DAG  built  in  the  route-search  phase.  Each  node  receiving  a 
RREP  establishes  or  updates  its  routing  state  for  the  destina¬ 
tion  specified  in  the  RREP.  This  information  is  used  for  data 
forwarding  and  route  maintenance. 

Interestingly,  the  design  of  on-demand  routing  protocols  to 
date  has  been  such  that  the  mechanisms  used  in  the  route- 
search  phase  to  propagate  RREQs  are  fairly  independent  of 
the  mechanisms  used  during  the  route-establishment  phase 
to  establish  and  update  routing-table  entries  for  destinations. 
Clearly,  SSLs  are  a  necessity  in  any  on-demand  routing 
protocol  for  the  identification  of  RREQs  and  their  efficient 
processing.  Eurthermore,  the  loop-free  paths  that  are  built 
during  the  route-establishment  phase  must  be  part  of  the  DAGs 
built  during  the  route-search  phase  based  on  SSLs.  This  begs 
the  question  of  whether  on-demand  loop-free  routing  can  be 
attained  using  SSLs  during  both  the  route  search  and  the  route 
establishment  phases  of  the  routing  process.  In  this  paper,  we 
present  the  first  framework  for  loop-free  on-demand  routing 
based  directly  on  SSLs.  Our  framework  supports  hop-by-hop 
packet  forwarding,  maintains  routing  tables  that  are  always 
loop-free,  and  operates  correctly  in  the  presence  of  state  loss, 
node  failures,  and  unreliable  message  delivery. 

Section  II  presents  an  approach  for  loop-free  routing  in 
which  the  destination  must  answer  all  RREQs.  Each  node 
relaying  a  RREQ  associates  a  relay-sequenced  label  (RSL) 
with  the  SSL  of  the  RREQ  it  forwards.  The  RREPs  traversing 
the  reverse  paths  along  the  DAG  built  by  the  RREQs  cause 
nodes  to  switch  successors  and  activate  the  route  along  this 
path.  However,  nodes  can  be  associated  with  multiple  RREQs, 
and  the  directed  graph  associated  with  the  aggregate  of  all  such 
RREQs  need  not  be  acyclic.  Hence,  to  ensure  loop-free  routes 
to  a  destination,  nodes  use  the  RSLs  to  accept  a  RREP  for  only 
one  SSL  and  drop  the  other  replies,  which  essentially  activates 
successor  entries  for  a  destination  within  a  single  DAG  created 
by  a  RREQ  SSL.  This  constitutes  the  first  component  of  our 
framework. 

Section  III  introduces  the  concept  of  a  viable  successor  set 
(VSS),  which  is  the  set  of  nodes  that  a  given  node  can  safely 
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pick  as  loop-free  successors  for  a  given  destination.  We  use 
this  concept  to  extend  the  approach  introduced  in  Section  II 
to  allow  intermediate  nodes  to  send  replies  to  RREQs  without 
creating  loops.  The  basis  for  this  approach  is  the  use  of 
label  sets  consisting  of  un-ordered  collections  of  SSLs  and 
RSLs  with  which  nodes  can  identify  viable  successors  towards 
destinations. 

Section  IV  presents  an  alternative  approach  to  extending  the 
basic  approach  of  Section  II.  This  approach  uses  the  SSL  and 
distance  to  a  destination  as  a  new  label  for  the  destination,  and 
uses  it  together  with  RSLs  to  ensure  loop-free  routing  while 
allowing  nodes  with  valid  routes  to  destinations  to  answer 
RREQs. 

Section  V  shows  how  instantiations  of  our  new  framework 
perform  compared  to  two  on-demand  protocols  (AODV,  DSR) 
and  a  proactive  link  state  protocol  (OLSR  [1]).  Results  are 
presented  for  50  and  100-node  networks  with  random  traffic 
flows.  Section  VI  provides  our  concluding  remarks. 

11.  On-Demand  Routing  Using  Source  Sequence 
Numbers  and  Destination  Replies 

We  present  an  approach  for  on-demand  routing  based  on 
the  SSLs  and  RSLs  carried  in  RREQs,  and  on  RREPs  issued 
only  by  destinations.  We  call  this  approach  DSLR  (destination- 
controlled,  source-sequenced  labeled  routing). 

A.  Information  Stored 

Node  A  has  a  unique  address  for  itself  {A)  and  maintains  a 
64-bit  source  sequence  number  ID  a  that  is  strictly  increasing, 
even  after  reboots.  This  can  be  achieved  by  deriving  the  source 
sequence  number  from  a  real-time  hardware  clock. 

At  node  A,  the  routing-table  entry  for  destination  D  con¬ 
sists,  at  a  minimum,  of  the  successor  (next-hop)  and  the 
start-identifier  SID^,  which  is  used  for  checking  if  a  certain 
neighbor  can  be  used  as  a  loop-free  successor.  SID^  is  set 
equal  to  IDJf^,  which  is  the  last  known  value  of  IDA{t)  at 
time  t  when  node  A  last  added  or  updated  its  routing  entry  for 
D.  Nodes  can  use  optional  metrics  for  choosing  successors. 
Possible  optional  entries  include  the  route-cost  (d^),  life-time 
of  the  route,  and  state  of  the  route  entry  (rt^)  (which  can 
be  valid  or  invalid).  The  route  entry  for  a  destination  can  be 
purged  at  any  time-instant  to  save  memory.  When  there  is  no 
routing-state,  the  value  of  SID^  is  set  to  IDA{t),  where  t  is 
the  time  that  node  A  first  originates  or  relays  a  RREQ  for  D; 
otherwise,  it  is  considered  to  be  invalid  (oo). 

B.  Control  Signaling 

The  basic  signaling  of  DSLR  consists  of  route  re¬ 
quests  (RREQ)  sent  by  sources  and  forwarded  by  relays,  and 
route  replies  (RREP)  sent  only  by  the  destinations.  Nodes  no¬ 
tify  route  failures  and  broken  links  using  route  errors  (RERR). 
Each  RREQ  is  identified  with  a  source-sequenced  label  (SSL) 
that  consists  of  a  (source,  identifier)  pair,  where  source  is  the 
node  address  originating  the  RREQ,  and  identifier  is  the  source 
sequence  number  ID  created  by  that  node.  RREPs  generated 
by  destinations  in  response  to  RREQs  must  carry  the  SSL  used 


to  identify  the  RREQ.  In  addition  to  the  SSL,  each  RREQ  and 
RREP  must  carry  the  relay-sequenced  label  which  is 

locally  assigned  by  the  node  relaying  the  RREQ  or  RREP,  and 
is  only  significant  within  the  one-hop  neighborhood. 

Node  A  is  said  to  be  active  in  a  route  computation  for 
destination  D  (i.e.,  the  RREQ)  when  it  initiates  a  RREQ  that 
is  uniquely  identified  by  the  pair  (A,  ID  a)-  A  node  relaying 
a  RREQ  (A,  I  Da)  originated  by  another  node  is  said  to  be 
engaged  in  the  RREQ.  A  node  that  is  not  active  or  engaged 
in  a  route  computation  for  destination  D  is  said  to  be  passive 
for  that  destination.  At  any  given  time,  a  node  can  be  the 
origin  of  at  most  one  RREQ  for  the  same  destination.  The 
RREQ  (A,  I  Da)  terminates  when  either  node  A  attains  a 
viable  successor  for  destination  D  or  the  timer  for  its  RREQ 
expires. 

We  define  the  following  five  rules  for  nodes  to  search  for 
routes  to  destinations.  RERR  handling  is  omitted  for  brevity 
and  is  identical  to  ones  used  in  previous  on-demand  routing 
protocols  [3].  We  use  the  notation  ID  a  to  denote  the  current 
source  sequence  number  at  node  A,  and  and  id’^^  to 

denote  the  value  carried  in  a  RREQ  or  RREP. 

•  Buie  1:  Node  A  must  increment  its  ID  a  each  time  it 
relays  or  originates  a  RREQ. 

•  Rule  2:  If  node  A  requires  a  route  to  destination  D, 
it  issues  a  RREQ  identified  by  SSL  (A,  ID  a)-  At  the 
originating  node,  the  RSL  and  the  SSL  for  the  same 
destination  are  identical. 

•  Rule  3:  If  node  B  (^  D)  receives  a  RREQ  identified 
by  SSL  (A,  idf^‘^)  from  neighbor  C,  it  caches  the  RSL 
(C,  idff'^)  for  this  SSL.  Node  B  processes  a  RREQ 
identified  by  a  SSL  only  once,  and  forwards  a  RREQ 
to  its  neighbors  with  the  SSL  created  by  the  source  of 
the  request  and  its  own  RSL  (B,  IDs), 

•  Rule  4:  When  node  D  receives  a  RREQ  from  neighbor 
I  that  was  issued  by  source  A  for  node  D  itself,  it  sends 
a  RREP  carrying  the  same  SSL  (A,  id^^^)  of  the  RREQ, 
and  the  RSL  (J,  idY'^). 

•  Rule  5:  When  node  I  receives  a  RREP  for  destination 
D  identified  by  SSL  (A,  id^^)  and  carrying  a  RSL 
(J,  idY^),  it  can  use  it  (if  it  is  feasible)  to  update  its 
routing  table;  if  it  does  so,  then  it  must  find  the  pair 
(B,  idY'^)  it  cached  for  this  (A,  idY^),  and  send  a  RREP 
to  neighbor  B  with  RSL  (BfidY'^)  and  SSL  (A,idY^)- 

Theorem  1:  If  rules  1  to  5  are  followed,  RREQs  and  RREPs 
do  not  loop  in  an  error-free  network. 

Proof:  Eor  a  given  route  computation  (A,  ID  a),  a  node 
may  be  passive,  engaged,  or  active.  A  node  can  become  active 
in  a  route  computation  at  most  once,  because  it  maintains  the 
identifiers  it  assigns  to  the  RREQs  it  originates.  A  router  can 
engage  in  a  route  computation  only  when  the  the  correspond¬ 
ing  RREQ  identified  by  (A,  ID  a)  has  not  been  previously 
processed.  Hence,  any  RREQ  can  traverse  only  a  directed 
acyclic  graph  (DAG),  which  may  be  a  directed  tree  if  no  node 
relays  the  RREQ  more  than  once,  and  any  path  traversed  by 
a  RREQ  is  free  of  loops. 


Because  RREPs  are  forwarded  along  the  reverse  path  tra¬ 
versed  by  the  corresponding  RREQs,  it  follows  that  the  RREPs 
must  traverse  loop-free  paths.  ■ 

Note  that  RREQs  may  loop  if  nodes  lose  their  cached  state 
for  a  computation.  However,  RREPs  will  not  loop,  as  long  as 
nodes  have  a  safe  loop-free  condition  when  accepting  them. 
Rule  5  requires  RREPs  to  be  relayed  only  if  they  are  accepted 
and  this  means  that  the  routing  tables  must  form  a  loop  in 
order  for  RREPs  to  be  relayed  in  loops. 

C.  Sufficient  Condition  for  Loop  Freedom 

Theorem  1  shows  that  the  RREPs  travel  loop-free  reverse 
paths  because  the  RREQ  identified  by  a  unique  SSL  build 
a  tree  rooted  at  the  source.  It  is  easy  to  see  that  no  loops 
can  form  if  every  node  in  that  reverse  path  to  the  source  is 
engaged  in  only  one  route  computation  for  the  destination. 
Based  on  this  observation,  we  obtain  a  sufficient  condition  for 
loop-free  routing  when  multiple  RREQs  are  present  by  having 
a  node  only  accept  a  single  computation  within  a  window  of 
computations.  After  accepting  a  computation,  the  node  drops 
all  other  route  computations  inside  that  window,  and  processes 
only  computations  from  a  new  window. 

We  use  the  following  terminology:  id{A)^g  denotes  the  id 
from  RSL  (A,  id)  in  the  RREP  for  destination  D  sent  by  node 
B  to  node  A.  id{B)^  is  the  id  from  RSL  (B,  id)  in  the  RREP 
that  A  receives  from  or  transmits  to  a  neighbor. 

Source  Sequence-number  condition  (SSC):  Node  A  can 
change  its  current  successor  for  destination  D  to  node  B 
at  time  f,  if  id{A)^g{t)  >  SID^{t),  where  SID^{t)  = 

We  establish  the  following  Lemmas  (  1  and  2)  when  nodes 
obey  rules  1  to  5,  and  use  SSC  for  switching  successors. 
Lemma  1:  SID^{ti)  <  SID^{t2),  where  Q  <  t2- 

Proof:  We  know  that  SID^ifi)  =  ID*j^{ti).  If  node 
A  never  updates  its  routing  table  till  time  t2,  then  SID^{t2) 
=  SID"^{ti).  On  the  other  hand  if  node  A  updates  route-entry 
for  D  at  time  t2,  then  it  can  only  be  the  case  that  ID^{t2) 
>  ID^(ti).  Therefore  SID^{t2)  =ID*j^{t2)> 

Even  if  there  is  a  reboot  or  state  loss  after  time  ti,  it  is  still  true 
at  time  t2  >  t  >  Q,  that  SID^{t)  =  IDA(t)  > 

Hence,  the  lemma  is  true.  ■ 

Lemma  2:  The  event  of  reporting  the  value  of  id{B)^  at 
time  t  to  neighbor  B  has  a  causal  relation  (denoted  by 
with  the  event  that  node  A  uses  a  value  of  id{A)^  to  update 
its  routing  table  at  time  t~,  where  t  =  t~  e,  assuming  that 
e  is  the  processing  time  for  updating  the  route  table. 

Proof:  By  Rule  5,  node  A  can  report  a  RREP  at  time  t 
only  if  it  used  a  RREP  to  update  its  routing  table.  Hence,  node 
A  must  have  used  the  value  of  id{A)^  reported  by  a  RREP  at 
time  t~ .  By  Rule  3,  node  A  must  have  a  stored  value  of  node 
H’s  RSL  for  this  RREP  identified  by  an  unique  SSL.  So,  by 
Rule  5,  node  A  reports  the  value  of  id{B)^  at  time  t  from  the 
cache  after  updating  its  routing  table  for  a  time  e.  Therefore, 
the  events  are  causally  related.  ■ 

Theorem  2:  If  nodes  use  SSC  to  change  successors,  no 
routing  table  loops  can  form. 
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Fig.  1.  SSC  loop-free  condition 

Proof:  The  proof  is  by  contradiction.  Assume  that,  before 
time  t,  the  directed  successor  graph  for  destination  D,  which 
we  denote  by  Sd(G)  is  loop-free  at  every  instant,  and  a  loop 
Ld{G)  is  formed  at  time  t.  It  is  easy  to  see  that  no  loops 
can  be  formed  unless  atleast  one  node  changes  its  successor 
at  time  f  to  a  node  that  is  upstream  of  itself  in  Sd{G). 

Assume  that  Ljj  (t)  is  formed  when  node  i  makes  node  a  its 
new  successor  (f)  after  processing  an  input  event  at  time  t, 
where  b  =  s^D  (tb)  f  a  and  tb  <  t.  Now,  Paoit)  must  include 

Pai{t). 

Let  Pai{t)  consist  of  the  chain  of  nodes  {a=  s[l,new], 
s[2,new],  ...,  s[k,new],...,i}  as  shown  in  Eigure  1.  The  notation 
indicates  that  node  s[k,  new]  is  the  hop  in  the  path  Pai{t) 

at  time  t,  and  has  node  s[kH-l,new]  as  its  successor  at  time  t. 
The  last  time  that  node  s[k,new]  updates  its  routing  table 

entry  up  to  time  t  and  sets  -f  1,  new]  is  denoted 

by  fs[fe+i,neu,]’  where  t^^k+i,new\  <  t-  Therefore,  it  is  true  that 

(fs[fc+l,neu)]  ti [t). 

Because  nodes  joining  PaD  do  not  switch  to  any  new  succes¬ 
sors  afterwords,  it  is  also  true  that 

The  time  when  node  s[k,new]  sends  a  reply  that  constitutes 
the  last  reply  from  such  a  node  that  is  processed  by  node 
s[k-l,  new]  up-to  time  t  is  denoted  by  fs[fe-i-i,oid] •  Node  s[k, 
new]’s  successor  at  time  ts[k-\-i,oid]  is  denoted  by  s[kH-l,  old]. 
Note  that  ts[k+i,oid]  <  ts[k-bi,new]  <  t,  and  that  s[k  -f  1,0^^] 
need  not  be  the  same  as  s[A:  -f  l^new].  It  is  also  true  that 

Erom  Rule  5  and  Lemma  2,  when  a  node  s[k,new\ 
relays  a  RREP  to  node  s[k  —  l,new]  at  time  ts[k+i,oid\  after 
updating  its  routing  table  at  time  it  must  be  true  that 

Because  SSC  must  be  satisfied  when  node  s[k,new]  G 
Paoit)  makes  node  s[kH-l,new]  G  Paoit)  its  successor  at 
time  ts[k+i,new]i  it  must  be  true  that 

Eor  a  loop  to  be  formed  after  t,  it  must  be  true  that  Paoit) 
exists.  We  now  derive  the  following  inequality  along  the  path 


Pai'^PaD  time  t,  if  nodes  satisfy  SSC  when  switching 
successors.  We  use  Lemmas  1  and  2. 
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The  invariant  conditions  along  this  path  lead  to  the  erro¬ 
neous  conclusion  that  SID}y{t)  <  SID\^{t).  Hence,  no  loops 
can  be  formed  when  SSC  is  applied.  ■ 

D.  Basic  Route  Maintenance 

1)  Route  Establishment:  Routes  to  destinations  are  es¬ 
tablished  on  demand  when  data  packets  destined  for  that 
destination  are  received.  Node  A  that  is  active  for  destination 
D  buffers  such  data  packets.  However,  if  node  A  is  passive  for 
destination  D  then  it  must  become  active  and  issue  a  RREQ 
as  per  Rule  2.  Node  A  maintains  a  RREQ  timer  that  is  set  to 
(2.  ttl.  latency)  for  every  destination  for  which  is  it  active,  where 
ttl  is  the  time-to-live  of  the  broadcast  flood  and  latency  is  the 
estimated  per-hop  latency  of  the  network.  If  no  usable  RREPs 
are  received,  node  A  resends  new  RREQs  with  an  increased 
ttl  after  the  expiry  of  its  timer.  If  node  A  does  not  receive  a 
RREP  for  destination  D  after  a  number  of  attempts,  a  failure 
is  reported  to  the  upper  layer.  The  number  of  hops  that  a 
RREQ  can  traverse  is  controlled  externally  from  the  RREQ 
by  means  of  the  TTL  field  of  the  IP  packet  in  which  a  RREQ 
is  encapsulated,  or  by  other  means. 

2 )  Updating  Routing  Tables:  Node  I  sets  ^  B  when  it 

accepts  a  RREP  from  neighbor  B  that  satisfies  SSC.  If  it  has 
an  associated  route  metric,  it  updates  <—  -I-  Ic^.  Note 

that  nodes  can  chose  to  accept  only  RREPs  that  will  result  in 
shorter-cost  paths,  although  it  is  not  necessary. 

E.  Termination  Properties 

Theorem  3:  All  nodes  in  a  connected  component  G  not 
containing  destination  D  invalidate  their  route  entries  for  node 
D  within  a  finite  time. 

Proof:  Prom  Lemma  1,  RREPs  generated  by  the  des¬ 
tination  cannot  traverse  loops.  A  finite  time  t  after  node  D 
is  partitioned  from  nodes  n  €  G,  all  RREPs  must  have  been 
processed  at  the  sources  that  originated  the  RREQs,  and  no 
more  RREPs  can  be  present  in  the  network.  The  DASG  for 
D  defined  by  the  successor  entries  of  nodes  in  G  is  loop- 
free  (Theorem  2),  and  in  a  finite  time  all  nodes  in  the  DASG 
must  be  notified  with  a  route  error  (RERR)  stating  the  un¬ 
reachability  of  D.  ■ 

Theorem  4:  In  a  stable  error-free  connected  network,  a 
source  S  will  establish  a  route  to  a  destination  D  in  finite 
time. 

Proof:  Prom  Lemma  1,  RREPs  generated  by  the  destina¬ 
tion  D  will  travel  a  loop-free  reverse  back  path  to  the  source 
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Fig.  2.  Using  SSLs  and  RSLs 


S.  If  every  node  along  the  path  updates  its  routing  table  for 
D  and  relays  the  RREP,  then  the  theorem  is  true.  However, 
if  a  node  is  engaged  in  multiple  route  computations  for  D, 
then  it  may  not  satisfy  SSC,  and  the  RREP  will  be  dropped. 
However,  in  such  a  case,  if  a  node  is  engaged  for  ’n’  different 
route  computations,  atleast  one  of  them  succeeds.  Because 
along  any  path  to  the  destination  from  the  different  sources, 
one  RREP  is  always  relayed,  atleast  one  source  must  always 
establish  a  path  to  the  destination  irrespective  of  how  many 
other  route  computations  are  on-going  at  the  same  time.  Given 
that  there  are  only  a  finite  number  of  sources  (nodes)  in  the 
network,  and  they  retry  new  RREQs  upon  failure,  eventually 
all  sources  must  establish  routes  to  the  destination.  ■ 

F.  Non-caching  Option 

Caching  of  the  RSL  associated  with  a  RREQs  SSL  can 
be  avoided  at  the  relay  nodes  if  the  RREQs  and  RREPs 
themselves  carry  the  entire  list  of  RSLs  generated  at  every 
relay  node.  This  is  beneficial  when  nodes  have  limited  storage 
capacity.  The  message  structure  of  such  a  RREQ  or  RREP 
would  be  a  tuple  {SSL,  RSLi,  RSL2, ...,  RSLn},  where  SSL 
is  assigned  by  the  originating  node,  and  each  RSLi,  where 
i  €  n},  is  appended  by  the  relaying  node  rii  and  is 

carried  as  a  list,  rather  than  being  cached  at  the  intermediate 
nodes  along  the  path.  It  is  also  possible  for  mixed-mode 
operation  where  some  set  of  nodes  can  operate  with  the  cache, 
while  the  ones  that  cannot  can  force  the  previous  hop  RSL  to 
be  carried  in  the  message.  Eor  example,  node  rii  can  flag  a  bit 
indicating  that  RSLni_i,  along  with  its  new  RSL^  must  be 
carried  in  the  RREQ.  This  ensures  that  enough  information  is 
present  in  the  RREP  generated  so  that  node  m  can  process 
and  relay  the  RREP  to  node  rii-i. 

G.  Example 

Eigure  2(a)  shows  the  sequence  of  events  in  a  four-node 
network  when  node  A  initiates  a  RREQ  for  destination  D 
identified  by  SSL  (A,l)  along  with  a  RSL  (A,l)  (that  is  the 
same  as  the  SSL  at  the  origin).  Node  B  caches  the  RSL 
(A,l)  for  the  SSL  (A,l)  and  sends  the  RREQ  with  its  RSL 


(B,l).  Similarly,  node  C  caches  the  RSL  (B,l)  and  sends  out 
a  RREQ  with  RSL  (C,l).  Destination  D  generates  a  RREP 
which  is  processed  by  nodes  B  and  C.  Assuming  that  the 
network  has  just  begun  operation,  when  the  nodes  A,  B,  and 
C  transmitted  the  RREQ  they  must  set  themselves  a  value 
of  one  for  SID^,  SID^,  and  SID^,  respectively.  Node  C 
can  accept  the  RREP  (A,l)  with  a  RSL  (C,l)  because  SSC  is 
satisfied  and  will  switch  its  successor  to  node  D.  Similarly, 
node  B  will  switch  successors  to  C.  Nodes  B  and  C  will  set 
their  respective  SID^  and  SID^  to  two  after  updating  their 
routing  tables  for  D.  Now,  assume  that  the  RREP  relayed  by 
node  B  is  queued  at  the  MAC  layer  at  time  ti.  Eigure  2(b) 
shows  the  sequence  of  events  after  time  ti,  when  node  C  can 
no  longer  reach  D  due  to  a  link  failure.  Node  C  sends  a  new 
RREQ  that  traverses  the  paths  PI  and  P2  through  node  A 
to  reach  destination  D.  The  RREQ  is  identified  by  SSL  (C,2) 
and  node  A  relays  it  with  a  RSL  (A,2).  Note  that  node  A  still 
has  a  stored  value  of  one  for  SID^. 

Eigure  2(c)  shows  the  state  of  the  network  at  a  time  t2  >  ti 
when  a  RREP  is  issued  by  the  destination  identified  by  (C,  2) 
and  the  nodes  along  path  PI  and  P2  update  their  routing  tables 
to  establish  a  route  to  node  D.  Node  A  sets  SID^  ^  3  to 
establish  its  successor  path  along  P2  after  updating  its  routing 
table.  When  the  RREP  identified  by  SSL  (A,l)  queued  at  node 
B  is  finally  transmitted  and  received  by  node  A,  it  can  form 
a  loop  if  node  A  decides  to  switch  successors  to  B.  However, 
because  SSC  must  be  satisfied,  node  A  can  only  accept  RREPs 
carrying  a  RSL  starting  from  (A,3)  as  SID^  =  3.  Therefore, 
the  RREP  will  be  dropped  and  no  loops  are  formed. 

Eigure  2  also  shows  the  window  of  RREQ  computations 
that  node  A  is  engaged  or  active  for  destination  D.  Node 
A  becomes  a  part  of  two  different  DAGs  created  by  the 
RREQs.  However,  the  directed  graph  formed  by  the  aggregate 
of  RREQs  with  SSL  (A,l)  and  (C,2)  is  not  acyclic.  Inside  this 
computation  window,  node  A  becomes  only  a  part  of  the  DAG 
created  by  RREQ  SSL  (C,2),  and  drops  the  SSL  (A,l).  The 
window  can  consist  of  more  RREQ  computations,  but  only 
one  of  them  is  used,  and  the  rest  of  the  computations  in  the 
current  window  are  dropped. 

III.  On-Demand  Routing  Using  Source  Sequence 
Numbers  and  Replies  from  Nodes  with  Valid 
Routes 

We  extend  the  basic  framework  of  the  previous  section  by 
deriving  labels  out  of  the  SSL  and  RSLs  carried  in  RREPs. 
These  labels  are  then  used  to  identify  neighbors  as  viable  loop- 
free  successors  to  the  destination,  which  allows  intermediate 
nodes  to  generate  replies.  We  call  this  approach  Source- 
sequenced  Labeled  Routing  (SLR). 

Eor  the  purposes  of  discussing  SLR,  we  use  the  non-caching 
version  of  routing  based  on  SSLs  presented  in  Section  II-E. 
We  later  show  how  it  can  simplified  to  the  caching  version. 

A.  Viable  Successor  Sets 

We  consider  the  generalized  class  of  on-demand  hop-by-hop 
ad  hoc  routing  protocols  that  use  a  RREQ  flood  identified  by 


Fig.  3.  Viable  Successor  Set  Dynamics 

an  unique  SSL  to  build  a  tree  rooted  at  the  source,  and  label 
one  or  more  of  the  reverse  paths  traversed  by  RREPs  along  the 
tree.  We  define  a  viable  successor  set  for  a  destination  D  at 
a  node  A  at  time  t,  denoted  by  VSS^{t),  as  the  set  of  nodes 
that  node  A  can  use  as  a  successor  to  destination  D  without 
causing  any  loops.  We  illustrate  how  VSS  varies  as  a  function 
of  time  when  using  a  labeling  scheme  such  as  AODV. 

Eigure  3(a)  shows  a  possible  assignment  of  destination 
sequence  numbers  (as  labels)  when  AODV  is  used  as  the 
routing  protocol  for  a  ten-node  network,  after  node  A  attempts 
a  route  discovery  for  destination  D  and  establishes  a  route  at 
time  t.  Node  A  uses  B  as  its  next  hop  for  destination  D 
because  it  offers  the  shortest  cost  path.  If  at  a  later  time  ti, 
link  AB  fails,  then  node  A  increases  its  destination-sequence 
number  to  two.  Any  new  RREQs  from  node  A  can  only  be 
answered  by  a  node  that  stores  a  destination-sequence  number 
greater  than  or  equal  to  two.  Because  of  the  labeling  adopted 
by  the  nodes,  VSS^  becomes  empty  (0)  at  time  G  as  none 
of  the  nodes  in  the  shaded  rectangle  can  satisfy  the  condition 
for  generating  a  RREP.  Consequently,  RREQs  from  node  A 
have  to  be  answered  by  the  destination. 

B.  Labeling  with  Source  Sequence  Numbers 

To  allow  nodes  with  active  routes  to  destination  D  to  answer 
RREQs  in  SLR,  each  node  stores  a  label  set  for  the  destination, 
which  is  an  un-ordered  collection  of  source-sequenced  labels 
and  relay-sequenced  labels,  together  with  its  self  source- 
sequenced  label  for  the  destination.  The  self  source-sequenced 
label  and  label  set  for  destination  D  maintained  at  node  A 
are  denoted  by  and  respectively.  The  label  set 

serves  the  purpose  of  other  nodes  identifying  node  A  as  a 
viable  successor  towards  destination,  while  the  the  stored  self 


sequenced-label  is  used  by  A  to  identify  other  nodes  as  safe 
viable  successors.  When  routing  state  is  lost,  it  is  considered 
that  LS^  =  0  and  =  {A,  oo).  Nodes  can  also  choose  to 
drop  any  of  the  elements  from  their  label  sets  for  a  destination 
at  any  time  without  affecting  correct  operation.  We  use  the 
term  sequenced-label  (SL)  to  refer  to  a  SSL  or  RSL. 

We  define  the  following  operator  (^)  to  determine  if  a 
sequenced-label  SLi  =  {srci,idi)  is  fresher  than  another 
SL2  =  {src2,id2)  as  follows: 

SLi  y  SL2,  if  srci  =  src2  A  idi  >  id2 

Labeling  Rule:  Let  node  rii  receive  a  RREP  satisfying  SSC 
for  destination  Uk  carrying  a  list  of  SLs  [{ni,idi),  (n2,id2), 
...,  (ni-i,idi-i),  (ni,idi),  ...,  (nk-i,idk-i)],  where  (ni,idi) 
is  the  SSL  and  the  other  sequenced-labels  are  RSLs  appended 
by  relaying  nodes.  Node  n*  performs  the  following  steps: 

•  Node  Tii  must  set  LS'"’=L/S'"‘  -  SL,  if  3SL',  such  that 
SL'  G  RREP  A  SL' t  SL. 

•  Node  Tii  can  assign  itself  a  label  set  LS'"’  C  LS'"’  U 
{(ni,idi),  (n2,id2),  ...,  (ni-i,idi-i)}. 

•  Node  Tii  can  set  =  (ni,idi).  However,  if  node  ni 
relays  the  RREP,  it  must  set  =  (rii,  idi)  or  to  (rii,  00). 

We  denote  the  individual  elements  of  the  label  L  with  src^ 
and  id^.  RREPs  carry  a  label  set  (LS)  which  is  set  to  LS^, 
where  node  A  is  transmitting  the  RREP  for  a  destination  D. 
The  label  set  stored  at  node  A  for  destination  D  reported  by  a 
neighbor  B  is  denoted  by  LS^g,  and  ID{LSi)gg  is  used  to 
represent  the  idi  of  the  SL  {I,  idi)  reported  in  the  label  set. 

Source-Sequenced  Labeling  Condition  (SSLC):  Node  A  can 
switch  successors  to  its  neighbor  B  for  destination  D  at  time 
t,  if  it  is  true  that  3  L,  such  that  L  G  LSgg(t)  and  L  A  Lg{t) 

(i.e.,  ID{LSA)Uit)>id^^it))- 

We  establish  the  following  lemmas  (3,  4,  and  5)  for  the 
labels  stored  at  a  node  A  when  SSC  is  used  for  RREP 
processing,  and  Rules  1  to  5  and  the  labeling  rule  are  adhered 
to.  We  assume  in  Lemma  4  and  5  that  there  exists  a  node  I  in 
the  network  that  is  active  or  engaged  in  the  route  computation 
that  node  A  is  also  engaged  for. 

Lemma  3:  id^^{ti)  <  id^^{t2),  where  ti  <  ^2- 

Proof:  Node  A  must  change  its  label  Lg  for  destination 
D  only  if  it  processes  and  relays  a  RREP.  To  accept  a  RREP 
at  time  t  as  per  SSC,  it  must  be  true  that  the  RREP  carries  a 
SL  (A,idA)  such  that  SIDg{f)  <  idA-  Node  A  will  re-label 
Lg  =  {A,  idA),  and  can  only  accept  RREPs  carrying  a  SL 
(A, id),  where  id  >  SIDg{t),  for  SSC  to  be  satisfied.  This 
is  true  even  after  reboots  or  state  loss  from  Lemma  1 .  Hence, 

tA 

the  value  of  id  °  is  strictly  non-decreasing  with  time,  and  the 
lemma  is  true.  ■ 

Lemma  4:  ID{LSi)g{ti)  <  ID(LSi)g(f2),  where  ti  < 
t2- 

Proof:  Eor  (I,  idi)  &  LSg,  it  must  be  true  that  node  A 
engaged  in  a  route  computation  for  which  node  I  is  active  or 
engaged  as  well.  The  proof  is  by  contradiction.  Let  {I,id\) 
and  {I,idj)  be  two  SLs  such  that  id}  <  id},  and  {I,  id})  G 
LSg.  We  will  now  prove  that  node  A  cannot  accept  a  RREP 


carrying  a  SL  (I,  id})  and  modify  LSg.  Node  A  must  have 
two  SLs  {A,  id}f)  and  {A,  id\)  engaged  in  a  route  computation 
along  with  node  J’s  SLs  to  receive  the  RREPs;  although  the 
relation  between  id}^  and  id\  is  not  known.  After  accepting 
the  RREP  carrying  a  SL  (I,  id}),  node  A  must  have  set 
SIDg  >  max{id\,id}f).  This  is  true  even  after  reboots  or 
state  loss  because  of  Lemma  1.  When  node  A  receives  the 
RREP  carrying  a  SL  {I,  id}),  it  cannot  satisfy  SSC.  Hence, 
node  A  will  not  modify  its  label  set  LSg.  Therefore,  the 
lemma  is  true.  ■ 

Lemma  5:  A  correspondence  (denoted  by  exists  be¬ 
tween  the  value  of  ID{LSi)g  reported  at  time  t  and  the 

r 

value  of  id  °  at  time  t~  <  t,  where  t~  denotes  the  time 
when  ID{LSi)g  was  added  to  or  modified  in  the  label  set 
LSI 

Proof:  Eor  ID{LSi)^  to  be  reported  at  time  t,  it  must 
have  been  added  to  the  label  set  at  a  time  earlier  than  t  when 
node  A  must  have  accepted  a  RREP  satisfying  SSC.  Lemma  4 
shows  that  the  value  of  ID{LSi)g  does  not  decrease  with 
time,  and  hence  t~  must  be  the  last  time  instant  when 
ID{LSi)i  was  modified  or  added  to  LSg.  As  per  labeling 

tA 

rules,  there  must  exist  a  defined  value  for  id  °  at  time  t~ , 
although  it  can  be  modified  at  a  later  time.  Hence,  the  value 
of  ID{LSi)^  reported  at  time  t  corresponds  to  id^^  at  time 

r. 


Theorem  5:  If  nodes  follow  labeling  rules  and  use  SSLC  to 
change  successors,  then  no  routing-table  loops  can  be  formed. 

Proof:  Using  the  same  argument  as  in  Theorem  2,  we 
derive  the  following  inequalities  along  path  Pai  C  when 
nodes  follow  labeling  rules  and  use  SSLC  to  switch  successors. 
We  use  Lemmas  5  and  3. 
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This  leads  to  the  erroneous  conclusion  that  id^o{f)  < 
id^T^it).  Hence,  no  loops  can  be  formed.  ■ 

C.  Simplified  Labeling 

We  have  previously  introduced  the  Labeled  Successor  Pro¬ 
tocol  (LSR)  [4],  which  can  be  considered  as  a  simplified 
version  of  SLR’s  labeling  scheme  making  use  of  only  the 
SSL  of  a  RREP.  LSR  can  be  derived  from  SLR  using  a 
subset  of  the  original  labeling  rules  as  follows:  When  node 
A  accepts  a  RREP  satisfying  SSC  identified  by  SSL  {S,  IDs) 
for  destination  D,  it  performs  the  following  steps: 

•  Node  A  must  set  LSg={{S,  IDs)}. 


.  Node  A  can  set  to  (S,  IDs),  if  5'  =  ^.  If  the  RREP 
is  relayed,  then  node  A  must  set  =  {A,  oo). 

The  two  stored  labels  used  can  be  replaced  with  one  as  is 
the  case  of  LSR  [4]  because  it  can  be  seen  clearly  that  only  one 
of  the  two  labels  are  useful  for  loop-free  checks.  LSR  lacks  a 
mechanism  to  sequence  RREPs  received  from  the  destination 
correctly.  The  simplified  labeling  of  SLR  used  to  realize  LSR 
does  not  suffer  from  this  limitation. 

D.  Example 

Eigure  3(d)  shows  an  example  of  VSS  dynamics  using  SLs. 
Source  A  starts  a  RREQ  flood  with  SSL  (A,  1),  which  gets 
relayed  along  paths  XYZ  and  BC  after  the  nodes  forward 
it  with  their  respective  RSLs.  The  RREPs  generated  by  the 
destination  (for  the  purposes  of  this  example,  we  assume  the 
destination  replies  to  all  received  requests)  are  processed  and 
the  nodes  set  their  label  sets  LS  as  shown  in  the  figure. 
There  is  no  explicit  ordering  of  nodes  here,  and  despite  the 
higher  hop  count  of  X,  node  A  can  still  switch  to  X  as 
a  viable  successor  applying  SSLC.  Here,  the  VSS^{t)  = 
{X,Y,Z,B,C}.  Note  that,  in-addition  to  node  A,  other  nodes 
can  also  identify  their  respective  viable  successors  for  the 
destination.  Assume  that  at  time  ti,  node  A  labels  path  PQR 
as  viable  successors  as  shown  in  Eigure  3(e).  Because  node  A 
does  not  relay  the  RREP,  it  can  still  retain  its  old  =  (A,l). 
Despite  switching  to  a  new  path,  node  A  can  still  use  all  the  old 
successors  at  a  later  time  and  the  VSS^{ti)  is  the  complete 
set  {B,C,X,Y,Z,P,Q,R}.  Node  A  is  able  to  determine  all 
the  nodes  that  were  previously  labeled  as  viable  successors. 
However,  as  per  the  labeling  rules,  if  node  A  had  relayed  the 
reply,  it  has  to  relabel  to  (A,  2),  which  will  force  A  to 
lose  viable  successors  from  its  old  RREQ  {A,  1).  The  other 
reason  the  VSS  can  lose  successors  at  a  later  time  is  if  the 
relay  nodes  along  the  path  drop  SLs  from  their  label  set. 

Eigure  4(a)  shows  another  example  of  the  labeling  for  a 
network  where  source  A  has  a  route  to  destination  D.  At  a  later 
time,  due  to  network  mobility,  node  C’s  link  to  D  fails.  Node 
C  re-establishes  a  route  to  D  through  a  path  CEAFD,  where 
E  and  F  are  new  nodes  that  are  in  this  vicinity  due  to  mobility. 
Eigure  4(b)  shows  the  labeling  at  this  time.  Subsequently,  if 
node  H’s  link  to  C  fails,  then  node  B  establishes  a  new  route 
through  BAFD.  Eigure  4(c)  shows  the  labeling  at  this  time. 
Note  that  the  re-labeling  occurs  in  these  cases  because  the 
RREP  is  generated  by  the  destination.  Note  that  in  both  these 
cases,  the  destination  is  the  only  node  answering  because  node 
C  or  B  cannot  identify  any  viable  successors.  The  label  sets 
stored  allow  nodes  to  be  identified  as  loop-free  successors  for 
a  destination  when  SSLC  is  used.  Eigure  5  shows  the  labeling 
for  the  same  set  of  events  when  LSR  (using  the  simplified 
labeling  scheme  of  SLR)  is  used  as  the  routing  protocol. 

E.  Route  Search 

We  present  three  conditions  for  SLR  that  are  used  by  nodes 
to  search  for  loop-free  viable  successors  across  a  single-hop 
or  multiple-hops  to  find  a  route  to  the  destination. 


We  redefine  the  is-a-subset-of  or  equal-sets  operation  (C) 
between  two  label  sets  LSi  and  LS2  as  follows: 

LSr  C  LS2,  if  V  SL,  SL  G  LS'i,it  is  true  that 
3SL' ,  such  that  SL'  G  LS2  A  SL'  A  SL 

Each  RREQ  carries  a  common  label  set  CLS  that  represents 
the  collection  of  self  SLs  of  each  node  that  transmitted  the 
RREQ.  The  purpose  of  the  CLS  is  to  find  a  loop-free  path 
from  a  successor  whose  RREP  is  usable  at  every  node  along 
the  reverse  path  to  the  originating  node.  We  use  superscripts 
req  and  rep  to  represent  the  values  carried  in  RREQs  and 
RREPs,  respectively.  The  conditions  for  initiating  RREQs, 
relaying  RREQs,  and  generating  RREPs  are  as  follows: 

RLSC:  (Reset  Labeled  Successor  Condition).  If  node  A 
must  change  (after  a  route  failure  or  if  =  0),  then 
it  must  send  a  RREQ  carrying  CLS'^‘‘  =  L^. 

GLSC:  (Generate  Labeled  Successor  Condition).  Node  I 
can  issue  a  RREP  responding  to  a  RREQ  req  for  des¬ 
tination  D  if  I  has  an  active  route  to  D,  and  CLS'^'^  C 

LSi,. 

CLSC:  (Common  Labeled  Successor  Condition).  When 
node  A  relays  a  RREQ  for  destination  D,  it  sets  CLS'i^'' 
=  CLS'j^'^UL^  in  the  relayed  RREQ  iff  CLS'j^’^  C  LS^. 
Otherwise,  CLS'^‘‘  is  set  to  0. 

We  illustrate  an  example  of  how  the  RREQ  search  pro¬ 
gresses  across  multiple  hops  to  find  an  intermediate  node  that 
can  reply.  Assume  all  nodes  in  Eigure  3(e)  except  node  R  have 
expired  their  route  for  destination  D.  Node  A  sends  a  RREQ 
with  CLS'j^''  =  {A,  1).  Eor  simplicity  we  consider  path  PQR. 
Node  P  relays  the  RREQ  with  CLS'i^'^  =  [(A,  1),  (P,  1)]  as 
per  CLSC  because  (A,  1)  C  LS^.  Similarly,  node  Q  relays  the 
RREQ  with  CLS]^'^  =  [(A,  1),  (P,  1),  (Q,  1)].  Now,  GLSC 
allows  node  R  to  initiate  a  RREP  that  will  satisfy  SSLC  at 


every  one  of  the  nodes  Q,  P,  and  A  when  the  RREP  traverses 
the  reverse  path. 

When  the  simplihed  labeling  scheme  of  SLR  is  used  in 
LSR,  nodes  can  only  identify  neighbors  as  successors.  Route 
searches  progressing  more  than  a  single-hop  can  only  be 
answered  by  the  destination. 

E  Termination  Properties 

The  proof  that  all  nodes  will  invalidate  their  routing  entries 
for  a  destination  that  is  partitioned  follows  directly  from 
Theorem  3  which  shows  that  the  property  holds  when  the 
destination  is  the  only  node  that  can  generate  replies.  In  SLR, 
according  to  Theorem  5,  the  DASG  is  instantaneously  loop- 
free  and  no  nodes  ever  choose  any  nodes  upstream  in  the 
DASG.  This  means  that  the  RERRs  that  propagate  along  the 
DASG  will  force  all  nodes  to  invalidate  their  route  entries  for 
the  partitioned  destination. 

Theorem  6:  In  an  error-free  stable  connected  network,  a 
source  will  establish  a  route  to  a  destination  in  finite  time. 

Proof:  Let  source  A  issue  a  RREQ  for  destination  ni 
that  traverses  a  path  P  =  {nfe,nfe_i,...,ni}  (where  n*  can 
be  Til),  before  reaching  the  destination  ni  or  a  node  that 
satisfies  SLSC.  If  CLS^ff  =  %,  then  the  RREQ  can  only  be 
answered  by  the  destination,  and  the  proof  follows  that  of 
Theorem  3.  Otherwise,  when  the  RREP  is  transmitted  along 
the  reverse  path  to  node  rii-i  by  node  rii,  it  is  true  that 
because  of  GLSC  and  CLSC.  Hence, 
node  rii-i  must  be  able  to  accept  the  RREP,  which  will  satisfy 
SSLC.  The  same  argument  holds  at  every  node  that  relays  the 
RREP  along  the  reverse  path  to  source  A.  If  a  node  along 
path  P  modifies  its  label  set  by  processing  another  route 
computation,  then  the  RREP  will  not  be  accepted  and  will 
not  be  relayed  to  the  source.  However,  sources  retry  RREQs 
and  there  are  only  a  finite  number  of  nodes  in  the  network. 
Prom  the  same  argument  as  in  Theorem  4,  each  source  must 
be  able  to  establish  a  route  to  the  destination.  ■ 

IV.  On-Demand  Routing  Using  SSLs  and  Distance 
Information  to  Allow  Replies  from  Nodes  with 
Valid  Routes 

As  the  last  component  of  our  loop-free  routing  framework 
based  on  SSLs  and  RSLs,  we  present  an  approach  with  which 
nodes  with  valid  routes  to  a  destination  are  allowed  to  answer 
RREQs  using  SSLs  and  distance  information  rather  than  label 
sets,  which  may  become  large  in  some  scenarios.  In  this 
alternative  approach  to  SLR,  which  we  call  Labeled  Source- 
sequenced  Routing  with  Distances  (LSR-D),  distances  are 
paired  with  SSLs  to  create  a  single  label  that  we  call  source- 
sequenced  distance  label  (SSDL).  SSDL’s  create  a  relative 
ordering  of  the  distances  along  the  path  in  which  nodes  are 
engaged  for  a  particular  RREQ  SSL,  and  the  source  of  the 
SSL  can  identify  all  nodes  in  the  path  as  viable  successors 
regardless  of  the  distances.  Showing  that  SSDLs  can  be 
safely  used  to  maintain  loop-freedom  can  be  proven  using  an 
approach  similar  to  the  one  presented  for  the  prior  approaches, 
and  is  omitted  due  to  space  limitations. 


A.  Sufficient  Conditions  for  Loop-freedom 

Each  source-sequenced  distance  label  (SSDL)  is  a  tuple 
[(SSL),  distance].  We  now  present  the  associated  terminol¬ 
ogy,  and  operations  on  these  labels.  The  freshness  operator 
(^)  between  two  labels,  SSDLi  =  [{srci,idi),di],  and 
SSDL2  =  [{src2,id2),d2]  is  defined  as  follows: 

SSDLi  >-  SSDL2  if  (srci  =  src2  A  idi  >  id2)  V 

(srci  =  src2  A  idi  =  id2  A  di  <1(2) 

We  denote  the  label  stored  for  a  known  destination  D 
at  node  A  by  SSDL^.  An  invalid  SSDL  at  a  node  A  is 
considered  to  be  [(A,  00),  0].  The  SSDL  reported  to  node 
A  by  neighbor  B  for  destination  D  is  denoted  by  SSDL^g. 
Each  RREP  carries  the  SSDL  and  distance  metric  (d)  at  the 
relaying  node  for  the  destination  denoted  by  We  denote 
the  cost  of  the  link  from  node  Axo  B  with  Ic^. 

Distance  Labeling  Rule  (DLR):  When  node  A  accepts  a 
RREP  from  neighbor  B  for  destination  D  that  satisfies  SSC 
and  that  is  identified  by  SSL  (S,IDs),  node  A  must  set 
SSDL"^=[{S,  IDs),d'],  where  if  S=A  then  d'  =  00  else 
d'  =  -f  Icg.  Node  A  can  choose  not  to  modify  a  valid 
SSDL^  if  it  does  not  relay  the  RREP. 

DLR  allows  nodes  to  assign  or  modify  (reset)  the  stored 
SSDL  for  a  destination.  This  may  be  done  after  the  loss  of 
state,  or  if  the  SSDL  stored  can  no  longer  be  used  to  determine 
any  viable  successors.  Note  that  DLR  requires  SSC  to  be 
satisfied;  therefore,  nodes  must  still  use  the  RSLs  to  determine 
which  RREPs  to  accept  and  such  RREPs  must  be  generated  by 
the  destination.  However,  if  nodes  have  valid  SSDLs,  they  can 
choose  a  neighbor  as  a  safe  loop-free  successor  by  comparing 
the  freshness  of  the  SSDLs  as  given  by  this  sufficient  condition 
for  loop-freedom. 

Source-Sequenced  Distance  Labeling  Condition  (SSDLC): 
Node  A  can  switch  successors  to  its  neighbor  B  for  destination 
D  at  time  t,  if  it  is  true  that  SSDL^g(t)  A  SSDL^(t). 

Ligure  6  shows  the  VSS  for  the  same  scenario  discussed  in 
Section  III-D  when  SSDLs  are  used  for  labeling.  We  assume 
link  costs  to  be  unity.  As  the  figure  illustrates,  a  relay  node 
B  with  SSDL  [(A,l),2]  can  identify  C  with  SSDL  [(A,l),l] 
as  a  viable  successor  without  using  extensive  label  sets.  Node 
A  can  still  identify  all  nodes  as  viable  successors,  because  its 
SSDL  is  set  to  the  highest  distance  (c>o).  SSDLs  also  allow 
nodes  to  identify  viable  successors  along  different  paths;  for 
example,  B  can  identify  Y  and  Z. 

B.  Route  Search 

Each  RREQ  carries  the  freshest  of  the  SSDL’s  stored  at  the 
nodes  along  the  path  traversed  by  the  RREQ,  which  is  denoted 
by  LSSDL.  We  define  an  in-order  operator  (□)  between  two 
SSDLs,  SSDLi  and  SSDL2,  as  follows: 


n{SSDLi,SSDL2) 


SSDL2,  if  {SSDL2  ^  SSDLi) 
(j),  otherwise 


Fig.  6.  Labeling  with  SSDLs 

We  briefly  describe  conditions  similar  to  that  of  SLR  for 
nodes  to  search  for  routes  across  one  or  more  hops  and 
when  intermediate  nodes  with  valid  routes  can  reply.  A  node 
A  issues  a  RREQ  with  FSSDL^^‘‘  =  SSDL^  for  desti¬ 
nation  D,  and  node  A  relays  RREQs  with  FSSDV^'^  = 
r\(FSSDL^^‘‘ ,  SSDL^).  An  intermediate  node  I  having  a 
valid  active  route  can  reply  to  a  request  if  SSDL^jj  >- 
FSSDL'^‘^ .  A  local-repair  operation  can  be  performed  by 
intermediate  nodes  to  repair  routes  locally  using  a  neighbor 
query  that  is  a  RREQ  with  ttl  set  to  one. 

The  in-order  operator  (□)  is  used  when  relaying  RREQs, 
because  a  previously  expired  path  to  the  destination  can  be 
activated  without  modifying  the  stored  SSDLs.  Eor  example, 
in  Eigure  6,  node  A  can  search  a  route  to  D  through  a  path 
PQR  because  the  the  SSDLs  are  in-order  and  every  RREQ 
will  be  relayed  with  the  stored  SSDL.  However,  if  the  RREQ 
traverses  a  path  PBC,  then  FSSDL  will  be  set  to  (j),  and  the 
RREQ  can  only  be  answered  by  the  destination,  which  will 
force  the  nodes  along  the  path  to  reset  their  SSDLs.  A  local- 
repair  can  be  performed  by  an  intermediate  node  B  without 
sending  a  RERR  to  source  A  when  its  current  link  to  C  fails. 
A  one-hop  RREQ  query  sent  will  be  answered  by  node  Y  or 

Q. 

V.  Performance 

We  present  results  over  varying  loads  and  mobility  for  an 
instantiation  of  DSLR  that  selects  shortest-cost  paths,  LSR, 
which  adopts  the  simplified  labeling  scheme  of  SLR,  and  LSR- 
D,  which  uses  SSDLs.  We  also  present  results  for  LSR-D-LR, 
which  is  LSR-D  with  the  local-repair  scheme.  The  protocols 
used  for  comparison  are  two  on-demand  protocols,  DSR  and 
AODV,  and  OLSR  [1],  which  is  a  pro-active  link  state  protocol. 
Simulations  are  run  in  Qualnet  3.5.2.  AODV,  DSLR,  LSR, 
LSR-D,  and  LSR-D-LR,  use  an  expanding-ring  search  scheme 
when  flooding  RREQs.  AODV  and  DSLR  set  the  ttl  of  the 
RREQs  to  the  last-known  hop-count  of  the  destination. 

Simulations  are  performed  for  two  scenarios,  (i)  a  50-node 
network  with  terrain  dimensions  of  1500m  x  300m,  and  (ii)  a 
100-node  network  with  terrain  dimensions  of  2200m  x  600m. 
Traffic  loads  are  CBR  sources  with  a  data  packet  size  of  512 
bytes.  Load  is  varied  by  using  10  flows  (at  4  packets  per 
second)  and  30  flows  (at  4  packets  per  second).  The  MAC 
layer  used  is  802.11  with  a  transmission  range  of  275m  and 
throughput  2  Mbps.  The  simulation  is  run  for  900  seconds. 


Node  velocity  is  set  between  1  m/s  and  20  m/s.  Elows  have  a 
mean  length  of  100  seconds  distributed  exponentially  between 
randomly  picked  sources  and  destinations  Each  combination 
(number  of  nodes,  traffic  flows,  scenario,  routing  protocol  and 
pause  time)  is  repeated  for  nine  trials  using  different  random 
seeds. 

We  present  four  metrics.  Delivery  ratio  is  the  ratio  of  the 
packets  delivered  per  client/server  CBR  flow.  Latency  is  the 
end  to  end  delay  measured  for  the  data  packets  reaching 
the  server  from  the  client.  Network  load  is  the  total  number 
of  control  packets  (RREQ,  RREP,  RERR,  Hello,  TC  etc) 
divided  by  the  received  data  packets.  Data  hops  is  the  number 
of  hops  traversed  by  each  data  packet  (including  initiating 
and  forwarding)  divided  by  the  total  received  packets  in  the 
network.  This  metric  takes  into  account  packets  dropped  due  to 
forwarding  along  incorrect  paths.  A  larger  value  for  the  data- 
hops  metric  indicates  that  more  data  packets  traverse  more 
hops  without  reaching  the  destination  necessarily. 

Tables  1  and  II  summarize  the  results  of  the  different 
metrics  by  averaging  over  all  pause  times  for  the  50  and 
100  node  networks  with  random  flows.  The  columns  show  the 
mean  value  and  95%  confidence  interval.  All  our  performance 
discussions  focus  on  the  average  case  because  the  confidence 
intervals  overlap  atleast  slightly  in  most  cases.  The  packet 
delivery  ratio,  the  end-to-end  delay,  and  the  control  overhead 
over  various  pause  times  is  shown  for  a  100-node  networks 
with  30-flows  in  Eigure  7  (results  for  LSR-D  are  not  shown). 
The  vertical  bars  in  the  graphs  indicate  the  95%  confidence 
intervals. 

The  performance  results  show  that  DSLR,  LSR,  and  LSR-D 
outperform  AODV,  DSR,  and  OLSR.  LSR  has  better  packet 
delivery  and  lower  control-overhead  than  DSLR  across  the 
different  scenarios.  This  is  because  the  labeling  in  LSR  allows 
one-hop  neighbors  of  the  source  to  initiate  RREPs,  thus  avoid¬ 
ing  RREQ  floods,  whereas  RREPs  in  DSLR  can  be  initiated  by 
the  destination  only.  Note  that  if  the  elaborate  labeling  scheme 
of  SLR  is  used,  it  is  also  possible  for  intermediate  nodes  that 
are  across  multiple  hops  from  the  source  to  initiate  RREPs. 
The  latency  of  DSLR  is  slightly  better  than  of  LSR  because 
DSLR  establishes  more  optimal  (shortest-cost)  paths  because 
RREQ  floods  search  for  the  destination  after  a  route  failure.  In 
the  case  of  LSR,  the  replies  from  intermediate  nodes  need  not 
necessarily  reflect  the  best  path  when  nodes  are  mobile.  The 
optimal  forwarding  of  packets  is  also  shown  in  the  data-hops 
metric  of  DSLR,  which  is  slightly  lower  than  that  of  LSR. 
LSR-D’s  performance  is  equivalent  to  that  of  LSR  across  the 
different  scenarios.  However,  the  local-repair  of  LSR-D-LR 
shows  a  noticeable  improvement  in  performance,  particularly, 
in  the  100-node,  30-flow  scenarios  where  excessive  RREQ 
flooding  can  cause  congestion.  The  local-repair  allows  nodes 
to  resolve  failure  without  reporting  a  RERR  to  the  source, 
which  will  then  retry  flooding  RREQs.  The  key  feature  is 
that  the  RREQ  sent  with  a  ttl  of  one  can  elicit  a  reply  from 
one  of  the  neighbors.  Although,  AODV  supports  a  local-repair 
operation,  it  floods  the  RREQ  to  locate  the  destination. 

The  performance  of  AODV,  DSR,  and  OLSR  suffer  from 


TABLE  I 

Performance  average  over  all  pause  times  for  50  nodes  network  for  10-flows  and  30-flows 


Flows 

10  1  30 

10  1  30 

10  1  30 

10  1  30 

Protocol 

Delivery  Ratio 

Latency  (sec) 

Net  Load 

Data  Hops 

DSLR 

LSR 

LSR-D 

LSR-D-LR 

AODV 

DSR 

OLSR 

0.996±0.001 

0.995±0.001 

0.995±0.001 

0.995±0.001 

0.994±0.002 

0.940±0.027 

0.887±0.040 

0.830±0.035 
0.859±0.038 
0.858±0.037 
0.867±0.036 
0.765  ±0.055 
0.683L0.059 
0.798L0.034 

0.016±0.002 
0.017±0.002 
0.025±0.005 
0.025±0.004 
0.016±0.003 
0.041  ±0.047 
0.012±0.001 

0.446±0.100 
0.480±0.170 
0.475±0.159 
0.442±0.159 
L010±0.356 
4.760±  1.073 
0.883±0.311 

0.271  ±0.067 
0.313±0.082 
0.374±0.093 
0.372±0.098 
0.270±0.066 
0.220±0.095 
L937±0.220 

3.566±0.821 
2.229±0.657 
2.226±0.628 
1.777±0.507 
4.423  ±1.289 
0.410±0.140 
0.713±0.069 

2.612±0.182 

2.628±0.186 

2.535±0.167 

2.539±0.168 

2.576±0.179 

2.677±0.185 

2.456±0.175 

2.617±0.172 

2.678±0.223 

2.675±0.224 

2.703±0.229 

2.951±0.324 

3.625±0.308 

2.478±0.161 

TABLE  II 

Performance  average  over  all  pause  times  for  100  nodes  network  for  10-flows  and  30-flows 


Flows 

1  10 

1  30  1 

1  10 

1  30  1 

1  10 

1  30  1 

1 

LJO _ 1 

Protocol 

1  Delivery  Ratio 

1  Latency  (sec) 

1  Net  Load 

1  Data  Hops  | 

DSLR 

0.991  ±0.004 

0.690±0.033 

0.034±0.006 

0.728±0.I07 

0.907±0.237 

IL845±L733 

3.851  ±0.307 

3.864±0.I94 

LSR 

0.990±0.004 

0.737±0.039 

0.042±0.007 

0.751  ±0.1 29 

L192±0.342 

8.213±L473 

3.814±0.314 

3.941  ±0.237 

LSR-D 

0.989±0.005 

0.738±0.039 

0.069±0.013 

0.754±0.133 

L462±0.412 

8.248±1.503 

3.690±0.302 

3.961±0.244 

LSR-D-LR 

0.988±0.005 

0.757±0.033 

0.069±0.013 

0.669±0.118 

L353±0.405 

6.229±1.154 

3.747±0.294 

4.020±0.259 

AODV 

0.988±0.004 

0.608±0.051 

0.036±0.009 

L455±0.385 

0.897±0.236 

18.298±13.069 

3.744±0.293 

4.751±0.434 

DSR 

0.876±0.050 

0.618±0.049 

0.099±0.057 

5.125±0.782 

0.859±0.353 

L243±0.405 

4.257±0.317 

6.141±0.499 

OLSR 

0.821±0.063 

0.612±0.041 

0.022±0.002 

3.371±0.532 

11. 795  ±1.575 

5.423±0.669 

3.583±0.256 

4.014±0.277 

Pause  Time  (Secs) 
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(a)  Packet  Delivery  (b)  End-to-end  Delay  (c)  Control  Overhead 

Fig.  7.  Scenario  with  random  sources  and  destinations  (100  nodes,  30  flows,  120  pps) 


the  following  problems:  AODV  suffers  from  excessive  RREQ 
flooding.  Note,  however,  that  DSLR  must  also  have  RREPs 
sent  by  the  destination,  making  it  almost  similar  to  AODV’s 
case.  We  noticed  that  AODV  was  generating  an  excessive 
number  of  RREPs,  and  yet  the  number  of  RREPs  received  at 
the  sources  was  far  smaller.  This  could  be  caused  by  RREPs 
being  forwarded  by  nodes  using  a  reverse  route  entry,  which 
is  only  valid  for  a  limited  time.  Hence,  with  congestion,  it  is 
possible  that  these  RREPs  get  delayed  and  are  dropped.  DSR 
suffers  from  stale  caches  and  source-routes  need  not  necessar¬ 
ily  reflect  the  topology  of  the  mobile  network.  OLSR  suffers 
from  temporary  loops.  The  number  of  messages  exchanged 
in  OSLR  is  constant  although  the  control  overhead  calculated 
depends  on  the  number  of  flows  in  the  network. 

VI.  Conclusion 

We  have  introduced  the  first  routing  framework  for  on- 
demand  loop-free  routing  in  MANETs  based  on  the  source 
sequence  number  that  is  used  to  identify  RREQs  originated 
uniquely.  We  presented  three  approaches  within  this  frame¬ 
work  (DSLR,  SLR,  and  LSR-D)  that  are  robust  to  node 
failures,  loss  of  information,  and  unreliable  message  deliv¬ 


ery.  They  allow  hop-by-hop  routing  of  data  packets  while 
maintaining  instantaneous  loop-freedom  of  the  routing  tables 
without  requiring  time-stamps,  source-routes,  or  any  other  syn¬ 
chronization  techniques  spanning  single  (i.e.,  packet  filtering) 
or  multiple  hops.  Performance  results  in  50  and  100-node 
networks  with  random  traffic  flows  show  that  protocol  instan¬ 
tiations  of  the  proposed  frameworks  consistently  deliver  more 
data  packets  than  DSR,  AODV,  and  OLSR,  while  reducing 
control  overhead  and  data  packet  latency. 
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